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Distributed Resource Metering System for Billing 

FIELD 

The present invention relates to billing systems. More particularly, the present invention 
relates to a distributed resource metering system used for billing. 

5 

BACKGROUND 

Practically everyone is famihar with receiving monthly bills for services such as phone, 
natural gas, and electricity. While some bills may be a flat monthly rate, many bills are for an 

6 

Q amount that is reflective of the quantity of services used. Companies that are paid based upon 

CO 

the amount of services consumed must have a method of determining an individual's usage rate. 
In addition, it is now more common for companies to provide pre-paid services. Companies 

I'll providing pre-paid services need to provide a method of informing consumers how much of the 

Q 

rfl service is remaining and how to purchase additional service. 

n 

Utility companies typically have meters that track the amount of natural gas, electricity, 
15 or water that is used by a facility. Usage bills are typically generated monthly based on meter 
readings. Phone companies have traditionally generated a call detail record (CDR) for each call 
made. The CDR contains the originating number, the receiving number, the start time, and the 
end time. This information is stored in a database. The phone company then downloads the 
information to determine how much each of the calls cost, which is based on the type of call and 
20 the customer's calHng plan. Typically, the phone company will bill the customer once a month. 

Companies that provide services over the Intemet also need a method of billing for their 
services. Many different devices can access the Intemet, such as computers, mobile phones, 
wireless handheld devices, and packet-switched telephones. These devices can be used to access 

2 



Express^ftl No. EL738028020US Deposited D^lfeber 6, 2001 

a variety of media chamiels, such as voice, video, instant messaging, Web browsing, and file 
downloading. Because there are so many different types of devices that can connect to the 
Internet and there are so many different media channels that these devices can access, companies 
providing these services need a billing system that allows for flexibility. Current billing 
5 programs are typically located behind a gateway so that the customer has no access to their real 
time account information. These billing programs download the billing information in a batch, 
similar to phone companies. While some companies may perform downloads more frequently 
than once a month so that customers can view their account on line, the information is not 
provided in real time. 

to It would be desirable to have a distributed resource metering system that provides real 

j il time billing information to consumers. By providing information to consumers regarding the 
13 quantity of services used and the associated costs in real time, they can make educated decisions 

rll regarding how to spend their money. 

Q 

If the consumer has purchased a pre-paid amount of service, it would be desirable to 

'Ci 

15 inform consumers how much of the service is still available and how to purchase additional 

services prior to depleting the account. It would also be desirable to cut off services to a pre-paid 

customer who has depleted their account. 

It would be desirable to provide application billing. A customer may be charged one rate 

for making a phone call and a different rate for downloading a game. The rate for the phone call 
20 may be based on time and location, while a rate for downloading a game may be based on the 

number of bits downloaded, unrelated to the time it took or the location of the file. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Various embodiments are described with reference to the following drawings, wherein: 
Fig. 1 is a simplified block diagram illustrating an exemplary distributed resource 
metering system; 

Fig. 2 is a simplified block diagram illustrating an exemplary billing client; 
Fig. 3 is an illustration of a display, according to an exemplary embodiment; 
Fig. 4 is a simplified block diagram illustrating an exemplary billing server; 
Fig. 5 is a simplified illustration of a service manager, according to an exemplary 



embodiment; 



i5| Fig. 6 is a simpUfied block diagram illustrating an exemplary distributed resource 

UJ metering system; 



Fig. 7 is a simplified block diagram illustrating an exemplary distributed resource 
metering system; 



rii 

'sas- 

|;[| Fig. 8 is a modeling diagram for a startup sequence, according to an exemplary 

15 embodiment; 

Fig. 9 is a modeling diagram for resource metering, according to an exemplary 
embodiment; 

Fig. 10 is a modeling diagram for resource termination, according to an exemplary 
embodiment; 

20 Fig. 1 1 is a simplified message flow diagram illustrating an exemplary distributed 

resource metering method; and 

Fig. 12 is a simplified block diagram summarizing an exemplary distributed resource 
metering method. 
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DETAILED DESCRIPTION 
I. Distributed Resource Metering System Components 

Fig. 1 is a simplified block diagram illustrating an exemplary distributed resource 
metering system 100. The distributed resource metering system 100 may include a billing client 
5 102, a billing server 104, at least one database 106, and an application server 108. The billing 
client 102, the billing server 104 and the application server 108 may be linked to a network 110. 
The network 110 may be/apacke^s^ such as the In"temet; 2r some other physical 

and/or wireless network. The network 110 may be a public or a private network. The billing 



iirj server 104 may be linked to the at least one database 106. Alternatively, the at least one database 

2 

{§ 106 may be a component of the billing server 104. 



A. Billing client 

Fig. 2 is a simplified block diagram illustrating an exemplary billing client 200. The 

j'll 

Q billing client 200 may be substantially the same as the billing client 102 of the distributed 
□ resource metering system 100. The billing client 200 is shown as a simple rectangular box in 

issls 

15 Fig. 2 to emphasize the variety of different forms the billing client 200 might take on from one 
embodiment to the next. For example, the billing client 200 might be any one of the following: a 
personal computer (PC), a mobile phone, a wireless handheld device, or a packet-switched 
telephone. The billing client 200 is not limited to any of these devices, and is intended to 
encompass future communication and information technology. 

20 The billing client 200 may contain a billing component 202, a display 204, and a client 

application 206. The billing client 200 may contain other client components, such as such as a 
phone pad, a keyboard, or a video screen. In addition, the billing client 200 may contain an 
application that allows the billing client 200 to communicate with the application server 108. 
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Although the billing component 202, the display 204, and the client application 206 are shown to 
be physically located within the billing client 200, other configurations may also be used. 

The billing client 200 may have at least one link to the network 1 10. The billing client 
200 may connect to the application server 108 through the network 110 employing phone 
gateways and network routers. The billing cUent 200 may be capable of accessing the Internet 
and executing a program to communicate with the billing server 104. 

The billing component 202 may contain software containing at least one program or 
routine that provides a means for the billing chent 200 and the billing server 104 to communicate 
with each other. The billing component 202 may be a Java applet running within a Java Virtual 
Machine, an Active-x control, a Microsoft DLL, or a SUO for Unix systems. The Java language 
is merely one implementation, and other languages and module types are also intended to be 
within the scope of the present system. The billing client 200 may communicate with the billing 
server 104 through any standard Internet communication protocol in place of Java seriahzed 
objects, such as Microsoft.NET platform. Sun Web Services, XML, and CORBA. 

The software in the billing component 202 may be encrypted. The biUing component 
202 may contain a decoder that interprets the encrypted software. For example, if the billing 
component 202 is a Java applet, the billing component 202 may be compiled byte-code. The 
byte-code may be a binary file containing an executable program that may be interpreted by the 
Java Virtual Machine. While th e billing component 202 is preferably software-based, one or 
more components may include hardware or firmware aspects. 

The billing component 202 may be upgraded, or otherwise modified, by transferring a 
new version of the billing component 202 to the billing client 200 after an end user activates the 
billing client 200. For example, after the end user activates the billing client 200, the billing 
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server 104 may check a flag to determine what version of the billing component 202 is loaded on 
the biUing client 200. If the latest version is not loaded, the billing server 104 may transfer the 
latest version of the billing component 202 onto the billing client 200. 

The display 204 may contain a Graphical User Interface (GUI). The GUI may be 
5 customizable for the particular type of biUing client 200. For example, the GUI on a cell phone 
may just display text, while the GUI on a computer may display a full range of graphics. The 
end user may be able to view substantially real time billing data. For example, while using 
services on the Intemet, the end user may be able to see the duration and the cost of the service 

O 

^ change on the display 204 in substantially real time. The end user may be able to view account 
tfl infomiation, such as how much a particular service will cost or how much was billed in the last 
thirty days, from the display 204. The end user may also be able to access an address book, add 



Ul 



Is.'. funds to his account, and send and/or receive instant messages from the display 204. 

ry 

Fig. 3 provides an illustration of the display 204, according to an exemplary embodiment. 

m 

P The display shown in Fig. 3 may be a typical display format. The text is in Japanese to 
15 demonstrate that the distributed resource metering system 100 may be used with many different 

languages and currencies. 

The client appUcation 206 may be any application server that requires resource metering. 

The client application 206 is depicted in Fig. 2 as being located within the billing client 200 to 

demonstrate that the application server may be integrated within the billing client 200. However, 
20 the client application 206 may be located separately from the billing client 200, such as the 

application server 108. The client application 206 may be operable to access and integrate with 

any number of services. 
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B. Billing Server 

Fig. 4 is a simplified block diagram illustrating an exemplary billing server 400. The 
billing server 400 may be substantially the same as the billing server 104 of the distributed 
resource metering system 100. The billing server 400 is shown as a simple rectangular box in 
5 Fig. 4 to emphasize the variety of different forms the billing server 400 might take on from one 
embodiment to the next. The billing server 400 may be an appUcation server, which may contain 
a combination of hardware, software, and/or firmware. In an exemplary embodiment, the billing 
server 400 may be a WebLogic Server manufactured by BEA Systems, Inc. of San Jose, 

•Vita 

Q Califomia. However other servers, such as Tomcat/Jakart, IBM Web Sphere, Allaire's JRun, or 

P 

W iPlanet Application Server, may also be employed. 

UJ 

^} The billing server 400 may include a billing manager 402 and a service manager 404. 



i If 



The billing server 400 may include other components. The biUing server 400 may have at least 



Q one link to the network 1 10. The billing server 400 may also have at least one link to the at least 

cn 

one database 106. The billing server 400 may support multiple languages and currencies. 
15 The billing manager 402 may manage data between the biUing client 102 and the at least 

one database 106. In an exemplary embodiment, the billing manager 402 may be a Java servlet. 

Other methods of managing data may be employed, including various combinations of software, 

hardware, and/or firmware. The billing manager 402 may receive a request fi-om the billing 

cUent 102, access the requested information firom the at least one database 106, and retum the 
20 requested information to the billing client 102. The billing manager 402 may track all active end 

users employing the application server 108, which may be managed by service manager 404. 

Fig. 5 shows a simplified illustration of the service manager 500 in an exemplary 

embodiment. The service manager 500 may be substantially the same as the service manager 



8 




ExpressWil No. EL738028020US Deposited DSImber 6, 2001 



404 of the billing server 400. The service manager 500 may be a collection that includes a list of 
substantially all the active end users. The collection may be stored in memory located on the 
billing server 400. For example, the collection may be stored in a hash table. The end user may 
access more than one media channel at a time. A record in the service manager 500 may 
5 represent an individual service request from one or more end users. Data located in the service 
manager 500 may include: the end user, the type of service requested, the associated rate for the 
combination of end user and service, the endpoint, and the duration. Other fields may also be 
1,^^ located in the service manager 500. For example, one of the records in the service manager 500 

h 

Q may identify: the end user, that the end user accessed a Web page to download a game, that the 

f& end user's rate for downloading a game is ten cents a minute, and that it took five minutes to 

Ul 

down load the game. The duration field would change substantially in real time as the download 
progressed. 



ry 

P| The billing server 400 may monitor communications between the billing client 102 and 

ii 

□ either a gateway or another billing client. The billing server 400 may monitor the duration, 
15 quality, and type of service. Other service characteristics may also be monitored. By tracking 
the duration of the service, the billing server 400 may bill the end user for only the amount of 
service that was consumed. By tracking the quality of the service, the billing server 400 may be 
able to adjust the bill if poor quality was detected. By tracking the type of service, the billing 
server 400 may provide application billing. For example, there may be one rate for a phone call 
20 and another rate for downloading a game from the Internet. The rate for the phone call may vary 
based on the rate plan assigned to the end user, the time of the day that call was made, the 
duration of the call, and/or the location of the end user receiving the call. The rate for 
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downloading a game may be based on the location of the game, the time it took to perfomi the 
download, and/or the total number of bits downloaded. 

In an exemplary embodiment, the conraiunication between the billing client 102 and 
billing server 400 may be performed using encrypted HyperText Transfer Protocol (HTTP). 
Other methods of secured communication compatible with the network 110 may also be 
employed. By using the billing server 400 to manage the communication, the gateway may not 
be required for biUing. The billing server 400 may provide the billing client 102 with gateway 
information for the service requested by the billing client 102. 

The billing server 400 may receive a Resource Utilization Update (RUU) on a periodic 
basis to update the service manager 404 regarding the activities being resource metered. The 
period of the RUU may be increased or decreased based upon the billing interval employed by 
the distributed resource metering system 100. For example, if the period is set to one minute, the 
billing server 400 may receive the RUU every minute. The RUU may be used to determine 
when communications between the billing client 102 and the gateway has been terminated. 

The RUU may be a program or routine used to determine if a particular network 
destination is online, such as a serialized Java object. A message may be transmitted on a 
regular interval, such as every minute, from the billing component 202 to the billing server 400. 
If the message stops being transmitted, the billing client 102 may no longer be connected to the 
network 110. The monitoring may allow the distributed resource metering system 100 to bill the 
end user for the actual amount of services consumed. For example, if the end user had indicated 
that he planned to make a thirty minute call and for some reason that call was interrupted after 
twenty-five minutes, the billing server 400 may detect that the call was interrupted and the end 
user would only be billed for the twenty-five minutes that was actually used. 
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When the billing client 102 is no longer active, the billing server 400 may delete the 
billing client 102 from the service manager 404. The billing information for the service may be 
stored in the at least one database 106. 

Fig. 6 is a simplified block diagram illustrating an exemplary distributed resource 
metering system 600. The distributed resource metering system 600 contains a primary billing 
server 604 and a secondary billing server 606. The secondary billing server 606 may be 
substantially the same as the primary billing server 604. Both the primary billing server 604 and 
the secondary billing server 606 may have access to the same databases. 



%i If for some reason the billing client 602 is unable to communicate with the primary 

1^ billing server 604, the billing client 602 may be transferred to the secondary billing server 606. 

Ul 

l%l The biUing client 602 may attempt to communicate with the primary billing server 604. If the 

'3 primary billing server 604 is not reached, the biUing chent 602 may be transferred to the 

in I 

secondary billing server 606. If the billing client 602 is unable to reach either the primary billing 

'ssiF 

server 604 or the secondary billing server 606, then the biUing client 602 may be unable to 

|;tss 

15 access the gateway. 

Because the secondary billing server 606 may have access to the same databases as the 
primary bilUng server 604 and the RUU may contain substantially all the data that the secondary 
billing server 606 needs to populate its service manager 404, the secondary billing server 606 
may be able to provide continuous monitoring and accurate billing for the service. By providing 

20 more than one billing server, the distributed resource metering system 600 may be redundant. 
Redundancy is an optional feature that may be provided to achieve various advantages, such as 
high availability. Other embodiments may include more than two billing servers. 
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C. Databases 

The at least one database 106 may be a component of the billing server 104 or a separate 
entity from the billing server 104. In an exemplary embodiment, the at least one database 106 
may be an Oracle database. However, other database products, such as IBM*s DB2 or 
Microsoft's SQL Server or PostgreSQL, may also be used. 

Fig. 6 shows that the distributed resource metering system 600 may contain multiple 
databases. The distributed resource metering system 600 is shown as having four databases; 
however, more or fewer databases are possible. It is also within the scope of this embodiment 



% that the fimctions of one database may be included within another. An exemplary distributed 

Q 

Wi resource metering system may contain one database with multiple tables. As shown, the 

l„y distributed resource metering system 600 includes a rating database 608, a presence database 

is 610, an account database 612, and a service database 614. Other databases or tables within a 

^ database may be used based on business needs. 

ill 

The rating database 608 may contain rate information. There are a number of different 
15 rate plans that may be assigned to the end user. The end user may be charged a different rate for 
the amount and type of service. A pre-paid account may pay a different rate than an account that 
is invoiced after the service has been consumed. Rates may vary based on where the service 
originates and where the receiving end user is located. Rates may vary for different types of 
service, such as phone calls, video conferencing, or downloading games. Rates may vary for 
20 different quantities of service. For example, a large quantity discount rate may be available. 

The rating database 608 may also contain currency and exchange rate information. This 
may allow the distributed resource metering system 600 to provide billing information for 
services in the currency of the end user's country. For example, the end user may be a citizen of 
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England. The distributed resource metering system 600 may produce substantially real time 
billing information and invoices using the sterling pound as the currency. 

The presence database 610 may contain substantially all of the connections to the 
network 616. If the billing client 602 wishes to communicate with another billing client, the 
5 presence database 610 may be able to determine whether the other billing cHent is connected to 
the network 616. 

The account database 612 may contain information regarding an end user's account. 
When the service is terminated, the record stored in the service manager 404 may be transferred 

jass 

^ to the account database 612. The end user may have access to this record the next time he 
tj^ activates the billing client 602. A bill may be generated and sent to the end user using the data 
ill stored in the account database 612. 

Ui: 

„ The service database 614 may contain a list of active services. The active services may 

flj include voice, video, instant messaging, and other media channels. Other services may be 
available. The service database 614 may contain gateway information, such as where the 
l^S^ gateway is located and whether it is available, 
D. A pplication Server 

Referring back to Fig. 1, the application server 108 may be any application server that 
requires resource metering. The application server may be accessible through the network 110. 
Altematively, the application server 108 may be accessible through a gateway connected to the 
20 network 110. For example, the appHcation server 108 may be a game server. As the billing 
client 102 downloads games from the application server 108, the billing server provides resource 
metering to bill the end user for the cost of downloading the game. 
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II. Distributed Resource Metering System Operation 

Fig. 7 is a simplified block diagram illustrating an exemplary distributed resource 
metering system 700. Distributed resource metering system 700 may contain at least one billing 
client 702, 704 and at least one billing server 710, 712. The at least one billing client 702, 704 
and the at least one billing server 710, 712 may be linked to a network 714. The network 714 
may be a packet-switched network, such as the Intemet or some other physical and/or wireless 
network. The network 714 may be a pubHc or a private network. At least one gateway 706, 708 
may also be linked to the network 714. 

A. Initialization 

The end user may activate the billing client 702. Activation may occur when the end user 
turns on the billing client 702. Other methods of activation may also be possible. The biUing 
client 702 may then run initialization routines. For example, the billing cHent 702 may launch a 
Java applet. The initialization routines may also run when the biUing client 702 has lost and then 
finds its signal, such as when a cell phone travels through a tunnel. The billing client 702 may 
be connected to the network 714 during initiahzation. 

The initialization routines may determine a format of a display 718. For example, the 
display 718 may have one format for a cell phone and a different format for a computer monitor. 
The format may also include language and currency preferences. End user preferences, such as 
weather, stock quotes, or game results, may also be formatted on the display 718. 

The end user may begin service by using the display 718, a keyboard, a video screen, or a 
phone pad on the billing client 702. For example, the end user may use the display 718 to access 
an address book and then select a name from the address book with the intention of sending 
another billing client 704 an instant message. 
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A billing component 716 located on the billing client 702 may send a request for service 
message to the billing server 710. The request for service message may include the type of 
service the end user desires. Other information may be included in the request for service 
message, such as end user identification, end user name, end user preferences, and status 
5 information. In an exemplary embodiment, the message may be in the format of a serialized 
encrypted Java object; however, other message formats may be employed. 

Communication between the billing client 702 and the billing server 710 may use 
HyperText Transfer Protocol (HTTP) and Transmission Control Protocol/Intemet Protocol 

Q (TCP/IP) protocols. Other conmiunication protocols that are compatible with the network 714 

9 

may also be employed. For example, the billing server 710 may be accessed as a web service. 

Co 

The billing client 702 may communicate to the billing server 710 using Simple Object Access 

jSSS 

Protocol (SOAP). The conmiunication may also be available over a Universal Description 
f|| Discovery and Integration (UDDI) directory using Web Services Description Language 
Si (WSDL). 

Q 

The billing server 710 may verify that the billing client 702 has the most recent billing 
component 716. The billing server 710 may check a flag, such as a binary software variable, to 
determine what version of the billing component 716 is loaded on the billing client 702. If the 
latest version is not loaded, the billing server 710 may transfer the latest version of the billing 
component 716 onto the billing client 702. 
20 The billing client 702 may desire to communicate with another billing client 704 or 

access a service through a media channel. Media channels may include, but are not limited to, 
voice, video, instant messaging, Web browsing, and file downloading. To access the media 
channel, the billing client 702 may use the at least one gateway 706, 708. Altematively, the 
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billing client 702 may access an application server directly, such as application server 108. In 
another embodiment, the client application may be located on the billing client 702. 

The billing server 710 may receive the request for service message from the billing client 
702. The billing server 710 may verify that the billing client 702 is authorized to make the 
5 service request. Verification may occur by accessing at least one database 722. The at least one 
database may be part of or separate from the billing server 710. If the billing client 702 is 
authorized, the billing server 710 may provide gateway information to the billing client 702. The 
l„b billing client 702 may then access the media channel directly using the at least one gateway 706, 
Q 708. For example, the billing client 702 may make a request for a video conferencing service. 

W The billing server 710 may authorize the billing client 702 for that type of service and send the 

Ul 

is! 

'f'^ billing client 702 information regarding gateway 706, which may provide video conferencing, 
l' Fig. 8 is a modeling diagram for a startup sequence, according to an exemplary 

rij 

Q embodiment. Fig. 8 is provided as an example for a browser based Voice over Intemet (VoIP) 

m 

CI PC-to-phone application. The VoIP application (G2Capplet) implements the initialization 
15 process for communicating with the billing server (CallMgr Servlet) to track calling charges for a 
PC-to-phone application. Other startup sequences may be employed for PC-to-phone 
applications, as well as for other distributed resource metering system applications. 
B. Resource Metering 

The billing server 710 may monitor the communications between the billing client 702 
20 and the at least one gateway 706, 708. The monitoring may be performed with a program or 
routine used to determine if a particular network destination is online, such as a serialized Java 
object. A message may be transmitted on a regular interval from the billing component 716 to 
the billing server 710. The billing server 710 may monitor whether the message stops being 
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transmitted. If the message stops, the billing client 702 or the at least one gateway 706, 708 may 
no longer be connected to the network 714. 

A Resource Utilization Update (RUU) may be used for monitoring. The RUU may be a 
serialized Java object; however, other methods of monitoring may be employed. In an 
exemplary embodiment, the RUU is transmitted to the billing server 710 every minute. The time 
may be increased or decreased based on a billing interval employed by the distributed resource 
metering system 700. The monitoring may allow the distributed resource metering system 700 
to bill the end user for the actual amoxmt of service used. 

If for some reason the billing client 702 is unable to communicate with the billing server 
710, the billing client 702 may be transferred to the billing server 712. The billing cUent 702 
may not be aware of the transfer from the billing server 710 to the billing server 712. Because 
5s the billing server 712 may have access to the at least one database 722 and the RUU may contain 

:[\ : 

II substantially all the data that the billing server 712 needs to populate its service manager 726, the 
billing server 712 may be able to provide continuous monitoring and accurate billing for the 
15 service. By providing more than one biUing server, the distributed resource metering system 700 
may be redundant. Other embodiments may include more than two billing servers. 

The billing server 710 may update its service manager 724. For example, the billing 
server 710 may change the duration field in the service manager 724 as the amount of service 
used increases. In addition, the billing server 710 may remove the billing client 702 from the 
20 service manager 724 when the billing client 702 is no longer connected to the network 714 or to 
the at least one gateway 706, 708. An update of the service manager 724 may occur during each 
billing interval. 
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During the service, the end user may be able to see the duration and the cost of the 
service change on the display 718 in substantially real time. The end user may also be able to 
view account information, such as how much a particular service will cost or how much was 
billed in last thirty days, from the display 718. The end user may also be able to detect that a 
pre-paid account is about to be depleted and may be able to fund the account for continued 
service. 

Fig. 9 is a modeling diagram for resource metering, according to an exemplary 
embodiment. Fig. 9 is provided as an example of a browser based VoIP PC-to-phone 
application. The VoIP application (G2Capplet) implements the resource metering process for 
communicating with the biUing server (CallMgr Servlet) to update service progress and calculate 
charges for a PC-to-phone application. Other resource metering sequences may be employed 
for PC-to-phone applications, as well as for other distributed metering system applications. 

C. Termination 

The billing client 702 may send a message to the biUing server 710 indicating that the 
billing client 702 is terminating the service. The end user may terminate the service by hitting an 
end icon or a button on the display 718. Other methods of terminating the service may be 
accomplished by using other cHent components, such as a phone pad, a keyboard, or a video 
screen. 

The service may be terminated when the billing server 710 no longer detects the RUU 
from the billing component 716. The billing server 710 may terminate the service after not 
detecting the RUU for a specified period of time. For example, the network 714 may drop the 
billing client's 702 connection to the at least one gateway 706, 708. 
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If the end user has a pre-paid account, the billing server 710 may terminate the service 
when funds in the accoimt have been substantially depleted. The billing server 710 may provide 
the end user with notice of the impending termination and allow the end user to fund the account 
through the biUing client 702. By allowing the billing server 710 to terminate service when pre- 
paid accounts have been depleted, the service provider may reduce a risk of non-payment of 
services. 

When either the billing client 702 or the billing server 710 has terminated service, the 
billing server 710 may remove the end user from the collection of active end users located on the 
service manager 724 and store the end user data in the at least one database 722. The billing 
client 702 may retrieve the data the next time the biUing client 702 runs the initialization 
routines. The billing server 710 may use the data in the at least one database 722 to generate a 
bill for the service, which may be submitted to the end user for payment. 

Fig. 10 is a modeling diagram for resource termination, according to an exemplary 
embodiment. Fig. 10 is provided as an example of a browser based VoIP PC-to-phone 
application. The VoIP application (G2Capplet) implements the resource termination process for 
communicating with the billing server (CallMgr Servlet) to terminate the service and calculate 
final charges for a PC-to-phone application. Other resource termination sequences may be 
employed for PC-to-phone applications, as well as for other distributed metering system 
applications. 

Fig. 11 is a message flow diagram illustrating a method 1100 for providing distributed 
resource metering system service, according to an exemplary embodiment. The entities shown 
as transmitting and receiving messages include a billing client 1102, a billing server 1 104, and at 
least one database 1 106. Various messages to be set forth below may be transmitted or received 
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by entities other than what is described. For example, the bilUng cHent 1102 may either have 
lower level components or may be included within higher level components, some of which may 
be involved in the transmission of messages, according to altemative embodiments. In addition, 
other messages may be transmitted or received that are not depicted in Fig. 1 1 . 

5 The billing client 1 102 may transmit a request for service 1 108 to the biUing server 1 104. 

The request for service 1108 may include a type of service requested and an end user 
identification code. The request for service may also include end user name, end user 
preferences, and status information. In an exemplary embodiment, the request for service may 

Q be in the format of a seriaHzed encrypted Java object; however, other message formats may be 

Ul 

W employed. 



^1 The billing server 1104 may receive the request for service 1108 from the billing client 



35B 



1102. The billing server 1104 may query 1110 the at least one database 1106 to determine 



fll whether the billing client 1102 is authorized to make a request and, if so, whether the type of 



ill service requested is available. The at least one database 1106 may provide the billing server 

liS^ 1 1 04 with database results 1112. 

The billing server 1104 may send a status message 1114 to the billing client 1102. The 
status message 1114 may indicate that the billing client 1102 is not authorized for the service 
requested. The billing client 1 1 02 may not be authorized for a variety of reasons, such as an 
invalid end user identification code, an unfunded end user account, or lack of access to the type 

20 of service requested. If the status message 1114 indicates that the billing client 1102 is 
authorized for the service requested, the billing server 1104 may provide the billing client 1102 
with information regarding how to communicate with a gateway, an application server, or 
another billing client. 
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The billing client 1 102 may access a service using the gateway, or directly contacting the 
application server or other biUing client. Once the billing client 1102 has connected with the 
gateway, the application server, or other billing client, the billing client 1102 may send a media 
channel active message 1 1 16 to the billing server 1 104. The billing server 1 104 may populate a 
service manager 1118 using information obtained from the at least one database 1 106. 

The billing client 1102 may transmit a RUU 1120 to the billing server 1104 at a billing 
interval rate. In an exemplary embodiment, the RUU is transmitted to the billing server 1104 
every minute. This time may be increased or decreased based on the billing interval employed 
by the distributed resource metering system. If the RUU stops, the billing client 1102 or the 



fflj gateway may no longer be connected to the network. 



\4 

m The billing server 1104 may continue monitoring the billing chent 1102 until the RUU 

stops, the billing server 1104 receives a message from the billing client 1102 to terminate the 



rU service, or the billing client 1102 no longer has fiinds in its account. A termination message 



1122 may originate from the billing client 1102 or the billing server 1104 depending upon how 



m 

1'5" the service was terminated. 

The billing server 1104 may remove the billing client 1102 from the service manager 
1 124 and store the record in the at least one database 1 106. The billing client 1 102 may retrieve 
the record the next time the billing client 1102 runs initialization routines. The billing server 
1 104 may retrieve the record from the at least one database 1 106 to generate an invoice itemizing 
20 the costs of the service to the end user. 

Fig. 12 is a simplified flow diagram illustrating a method 1200 for providing distributed 
resource metering system service, according to an exemplary embodiment. In 1202, the billing 
client 102 may be initialized. This may occur when the end user turns on the billing client 102 or 

21 
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when the billing client 102 loses and then finds its signal In 1204, the billing client 102 may 
send a request for service to the billing server 104. In 1206, the billing server 104 may query the 
at least one database 106 to determine if the billing client 102 is authorized for the service. In 
1208, the billing server 104 receives the results of the at least one database 106 query. 
5 In 1210, the billing server 104 transmits the status of the at least one database 106 query 

to the billing client 102. The status may include whether the billing client 102 is or is not 
authorized to use the service. If the billing cUent 102 is authorized to use the service, the billing 
client may access a media channel through the gateway, or directly contact the application server 

issk 

P% or other billing client. In 1212, the billing client 102 may notify the billing server 104 that the 
Wi billing client 102 has connected with the gateway, application server, or other billing client. In 
\m 1214, the billing server 104 may populate the service manager 404 with data obtained from the at 
least one database 106. In 1216, the billing server 104 may monitor the communication between 



the billing client 102, and either the service or the other billing chent using the RUU. In 1218, 



fn 

either the billing client 102 or the billing server 104 may terminate the service. Much of the 
15 functionality described with reference to Figs. 1-11 may also be included in the method 1200. 

In view of the wide variety of embodiments to which the principles of the invention can 
be applied, it should be understood that the illustrated embodiments are exemplary only, and 
should not be taken as limiting the scope of the present invention. For example, more or fewer 
elements or components may be used in the block diagrams. In addition, the present invention 
20 can be practiced with a combination of software and hardware. 
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